你剛介紹完一個需求：「我們希望在後台新增一個『訂單搜尋』的功能，讓客服可以透過訂單編號，快速找到對應的資料。」

你熟練地運用了 病症07 的拆解技巧，和團隊一起把所有細節都攤在陽光下。接著，你也專業地運用了 病症08 的引導式提問，和團隊一起進行了三點估算法。

最終，團隊的資深工程師阿傑，給出了一個結論：「嗯，考慮到各種例外狀況和測試，這個功能我們評估需要兩週。」

你看著這個數字，心中卻警鈴大作，因為根據你過去的經驗以及你對團隊能力的了解，這個功能最多、最多一週就綽綽有餘了，你感覺一種深層的無力感混合著懷疑，在你的腦海中蔓延開來。

PM 內心小劇場

在這一刻的你，沒有意外的話可能大腦會經歷這些小劇場：

第一幕：懷疑
你腦中的「質疑者」會率先登場：「兩週？太誇張了吧！他是不是在唬我？是不是想偷懶？是不是把其他事情的時間也灌到我這個專案裡了？」你開始把工程師當成對手，思考該如何戳破他的謊言。

第二幕：恐懼
接著，來自外部的壓力會抓住你。你想到老闆昨天才在會議上強調 Time to Market 的重要性，要求這個功能要 as soon as possible 。如果你真的拿著兩週這個時程去報告，老闆肯定會質疑你的能力：「一個小小的搜尋功能要兩週？你是怎麼帶團隊的？」

最終，在內外夾擊之下，你可能一不小心脫口而出：「兩週太久了，我覺得一週就可以，你們加加油！」

當這句話一出口，你和團隊之間那道無形的牆，就瞬間又增厚了一公尺。

工程師心裡不免俗會想著：「不懂技術還給我亂砍什麼時程？」，而你心裡可能也想著：「這群工程師就是只想著多報時程偷懶！！！」

這，就是為什麼我們需要建立信任。因為如果失去了信任，所有的估算，都會變成 PM 與 RD 的一場諜對諜的心理戰，到最後只會兩敗俱傷呀！

症狀診斷

當團隊有這個狀況的時候，那麼我想可以確診為「防禦性時程緩衝症」。

這個病症是病症 08 的鏡像症狀。

• 病症 08 的根源，是團隊過於樂觀。
• 而這個病症的根源，則是團隊過於悲觀（或者說是過於自保）。

病根在於團隊過去可能經歷了太多「需求不斷變更」、「時程被任意壓縮」、「出了問題就被抓來祭旗」的創傷。所以想當然爾，工程師們久而久之就學會了自保，在每一次的時程估算中，都預先為自己加上厚厚的防禦性城牆，也就是所謂的 Buffer 。

這個 Buffer，不是為了應對技術風險，而是為了應對「變更風險」。

我們要嘗試的，不是把工程師報出來的時程當作「成本」，想盡辦法去「砍價」；而是把這個時程當作一個「信號」，去探究數字背後，團隊真正擔憂的是什麼。

你的工作，不是去拆穿一個謊言，而是去拆除一座城牆。

處方籤

以下提供三劑處方，幫助你在遇到上面的場景時，可以採取怎麼樣的措施。

第一劑：先治療你自己的「懷疑病」

在質疑團隊之前，先問自己三個問題：

1. 我是否創造了一個「朝令夕改」的環境？我是否常常在 Sprint 中途 / 專案中途，拿著老闆的「聖旨」去變更需求？
2. 我是否扮演了「壓力傳遞者」的角色？ 我是否只是把業務和老闆的焦慮，原封不動地轉嫁給團隊？
3. 我是否在出問題時，成為了團隊的「保護傘」？ 還是我會為了自保，而把責任推給工程師？

如果對以上任何一個問題的答案不是那麼肯定，那麼問題的根源可能反而在我們自己身上。

第二劑：用「透明化」取代「猜心」

不要自己悶著頭猜團隊是不是在灌水。把你的困惑，變成一個開放的團隊討論。

建議的提問說法

「夥伴們，感謝你們的評估。目前我們估出來的時程是兩週。同時，業務那邊期望能在一週內看到成果。這中間有一個禮拜的差距。我想和大家一起看看，有沒有什麼方法，可以幫助我們縮小這個差距？是不是有哪些需求，我們可以先做簡化版？或者，是不是有哪些潛在的風險，是我沒有考慮到的，讓大家覺得需要預留比較多的緩衝時間？」

溝通框架拆解

上面是一個範例的說法，我們來拆解一下整段話的框架，這樣下次遇到其他的情境狀況，你就可以參考這樣的框架來進行提問。

• 感謝開頭：以「感謝你們的評估」開頭，首先肯定團隊的貢獻，建立尊重的基調。
• 事實陳述：「目前我們估出來的時程是兩週。同時，業務那邊期望能在一週內看到成果。」客觀陳述兩方期望，不帶個人判斷。
• 問題定義：「這中間有一個禮拜的差距。」明確指出需要解決的具體問題。
• 邀請協作：「我想和大家一起看看」轉換為共同解決問題的模式，而非進入到互相對抗的模式。
• 方案引導：先提供兩種可能的思考方向（簡化需求或辨識風險），引導團隊思考。
• 開放式結尾：問句結尾讓團隊有發言空間，不是命令或單向溝通。

採取這樣的問法，能讓你從一個質疑者，變成一個尋求工程師幫助的合作夥伴。

第三劑：建立「安全的」實驗環境

如果團隊因為害怕失敗而不敢給出積極的時程，那就創造一個「就算失敗了也沒關係」的環境。

建議的提議說法

「我理解大家對這個新技術比較沒把握，所以估得比較保守。沒關係，那我們來做個實驗。我們就先承諾一個比較樂觀的時程，但同時，我也會跟老闆說清楚，這是一個技術探索，有延遲的風險。如果真的延遲了，責任由我來扛。我希望大家能放膽去試。」

溝通框架拆解

一樣讓我們來拆解這段溝通的框架：

• 同理開頭：「我理解大家對這個新技術比較沒把握」先表達理解團隊的擔憂，建立共情基礎。
• 正常化問題：「所以估得比較保守。沒關係」接受現狀並減輕團隊的心理壓力。
• 提出解方：「那我們來做個實驗」將困境轉化為嘗試的機會，改變框架。
• 降低風險感：「我也會跟老闆說清楚，這是一個技術探索，有延遲的風險」提前設定適當的期望值。
• 承擔責任：「如果真的延遲了，責任由我來扛」明確表達願意作為團隊的後盾，消除團隊恐懼。
• 賦能結尾：「我希望大家能放膽去試」鼓勵團隊冒險創新，建立信任文化。

特別門診：如何從根本上，治癒團隊的「信任缺乏症」

上面的處方籤能幫你處理當下眼前的危機。但這其實只是治標不治本，如果要從根本上拆除團隊心中的「防禦性城牆」，你需要長期抗戰！

以下分享幾個建議的方法，希望可以幫助你跟團隊重新建立連結與信任感！

第一帖補藥：成為團隊的「過濾器」與「防彈背心」

團隊之所以需要 Buffer，是因為他們害怕來自四面八方的隕石打亂原本的節奏，所以把時程直接連處理隕石的部分都估計進去，所以，你的首要職責，就是成為他們最可靠的屏障。

• 過濾需求變更
  你必須建立一個清晰的需求變更流程。當老闆或業務又帶著「靈光一閃」衝進來時，你要溫和但堅定地說：「這個想法很棒，我先把它放進我們的『需求池』，在下一次的規劃會議上，我們再來評估它的優先級。」
• 吸收外部壓力
  當老闆對時程有疑慮時，你要一肩扛起溝通的責任。不要把壓力原封不動地轉嫁給團隊，而是需要自己先消化、分析，然後帶著具體的選項去和團隊討論。

第二帖補藥：擁抱「脆弱」，承認自己的不完美

信任是雙向的。如果你希望團隊對你誠實，你必須先對他們誠實。

• 主動承認錯誤
  當你犯錯時（例如：需求沒問清楚、時程沒溝通好），要在團隊面前坦誠地說：「各位，這件事是我沒做好，我向大家道歉。下一次我會改進。」
• 分享你的不確定性
  在面對一個模糊的需求時，不要假裝自己什麼都懂。你可以說：「坦白說，這個需求我也還沒完全想清楚。我們能不能一起來拆解，這樣我也會更明白這件事情的難點？」

通常當團隊看到，連 PM 都願意承認自己的脆弱與不完美時，他們自然而然也會更願意放下武裝，分享自己真實的擔憂與不確定性。

第三帖補藥：將「估算」從一場考試，變成一次學習

許多團隊害怕估算，是因為通常估算是否準確會變成評估他能力的一個定生死考核，你需要帶頭改變這個習慣、這個規則。
你可以在複盤會議上，當一個任務的實際耗時與估算有落差時，你的重點不是「為什麼不準」，而是「我們從這次的落差中，學到了什麼？」

最後的醫囑

所以，下次當你聽到一個讓你眉頭一皺的時程估算時，請先別急著開口砍價。

一個過長的時程估算，往往不是技術問題反而是安全感的問題。

我們的工作，不是去當一個精明的「採購」，試圖用最低的預算買到最多的工時；我們需要去傾聽數字背後，那些團隊成員不敢說出口的恐懼與擔憂。

當你的團隊不再需要用「謊言」來保護自己時 ，當你從「砍價」的心態轉變為「培養心理安全感」的思維時，你會慢慢地發現，工程師們給出的時程不僅越來越貼近真實，有時候甚至比你預期的還要短。

因為他們不再需要那堵防禦性的城牆，他們知道在你的團隊裡，說真話是被鼓勵的、失敗是可以被接受的，而成長才是最終的目標。（OS：啊，怎麼感覺跟小孩教育也是滿像的）

能找到值得互相信任的同事

且珍惜